1. Field of the Invention
Embodiments of the present invention generally relate to peer-to-peer SIP communications, and, in particular, to a system and method for replacing back-to-back user agents with armed rich endpoint directives.
2. Description of Related Art
The infrastructure for Session Initiation Protocol (“SIP”) currently requires applications that handle calls to monitor and receive messages in a signaling path to an endpoint. Such an application may be referred to as an in-sequence application. A SIP-compatible in-sequence application is usually implemented as a back-to-back user agent (“B2BUA”) in order to provide various services. Currently, such applications must remain in the core signaling path of the call and continuously monitor for certain conditions that must be intercepted.
Furthermore, providing SIP-compatible features executing in the network core involves extensive effort and time in order to create and develop centralized core applications, thereby slowing down the pace of deployment and availability of such features to the customer. Core SIP applications also increase feature and signaling complexity by breaking a peer-to-peer nature of the call flows. In-sequence applications, which currently need to be present in order to monitor the call signaling are difficult to develop, are large and resource-intensive when they run, expensive, and are hard to scale centralized applications. The in-sequence applications cause most or all of the communication traffic to traverse through the back to back application, potentially causing latency problems.
Furthermore, having too many in-sequence applications slows down the call transmission.
SIP back-to-back applications are prone to breaking features (i.e., causing features to fail) if they are not properly designed, including that of properly forwarding the call signaling as the call passes through the B2BUA.
Even with the advent of smarter endpoints in SIP, there are still a large number of scenarios that currently require a back to back application resource to perform actions when certain conditions are met. For example, in the case of a post-call survey, an application must currently monitor a call path, ahead of an endpoint in a processing sequence, and monitor for an indication that the call is disconnected. Upon end of the call, the call is intercepted before it can be disconnected. Instead of allowing the call to be disconnected, the application then transfers the call to a survey Interactive Voice Response announcement.
Additional examples of core SIP features that currently require a B2B are: (1) recording a call; (2) invoking certain features such as limiting call duration, limiting billing applications, etc.; and (3) call preservation.
Methods of the related art may use configuration settings or administration settings to provide a limited level of customization or control. However, such settings are too static and do not provide the necessary dynamic control needed so that features can be invoked at any time.
Methods of the related art may use feature Uniform Resource Names (“URNs”), which may be triggered by an application that is constantly monitoring the SIP signaling and media and, when invoked, the application provides an immediate action. URNs are described more fully in RFC-5031. A drawback of this method is that it is a service that needs to be invoked right away, and hence does not include a way to delegate the monitoring of a condition to an endpoint. Furthermore, monitoring media by an application is expensive and impractical, especially when scaled to large volume of concurrent calls.
Methods of the related art may use monitoring applications that are not in sequence (i.e., not constantly monitoring the SIP signaling). However, a drawback of such a method is that such monitoring applications are limited in their control. For example, such monitoring applications are unable to be in a media path and therefore are unable to watch for media-related triggers.